It is known to use various types of electronic systems in all manner of consumer goods. Such systems typically include some means of receiving instructions from the consumer, a controller such as a microprocessor on a silicon chip, and peripheral devices such as sensors and output generators. A microwave oven, for example, may be instructed by a consumer who pushes a series of buttons to tell it to generate microwaves at a given power level for a given period of time. A more complex oven may include a sensor that will automatically cut off operation once a given temperature is reached. A far more complex example would be anti-lock brake and traction control systems such as the ones described in U.S. Pat. No. 5,487,595 issued to Wise, et al., Jan. 30, 1996.
Each of the above-described systems is dependent upon software, which is a pattern of instructions that operates on the microprocessor and its peripheral devices. The nature of the software, in turn, is influenced by the final design of the microprocessor and peripheral devices. In a normal product development cycle, both the peripheral devices and the software are likely to be changed, and the microprocessor may also change. Further, once a product design has been finalized, the product must be tested in a wide variety of circumstances to assure a manufacturer that the product will function as expected. Consequently, product development cycles of 3-5 years are not uncommon. An advantage of the present invention is that the time frame for a product development cycle may be reduced by increasing the efficiency of software testing. The inventors have devised a faster means of verifying whether software will operate on an electronic system in the expected manner, by simulation.
Various forms of circuit simulators are known. As used herein, the term circuit simulator means a software-driven system used to predict the behavior of electrical circuits or other physical systems. Given a description of a circuit and a stimulus, the simulator produces the response, or output, of the circuit to the stimulus.
Generally, the user describes the circuit to the simulator by giving a list of components and a specification indicating how they are interconnected. Each component is described in terms of its elements such as transistors, capacitors and resistors. The simulator has a mathematical model of each element of each component, and given a list of components, it is able to formulate a system of equations. The simulator then solves the system of equations and presents the solution to the user as the response of the circuit. The process of solving the system of equations is often a multipass process where the output of one element becomes the input to another element. In that case, multiple simulation passes must be performed in order to obtain the response of the circuit to the original stimulus. Where large numbers of circuit elements are involved, the number of calculations and their interrelationships becomes very large, very quickly. Also, the purpose of the simulator is to "put the system through its paces", that is, test the system in as many different situations as its creators can imagine a consumer might encounter. As a result, the process of performing a simulation can become unwieldy, and very time-consuming.
This detailed simulation of a circuit, or circuit-level simulation, is done when the operation or behavior of the circuit is first being developed and designed. Large circuits can contain millions of elements. Simulation of the circuit is necessary in order to analyze the interaction of all of the elements because it is impractical to physically build a new circuit every time a change is being considered. However, the speed of the simulation is slow due to the large number of calculations involved.
Several strategies for increasing the speed of simulation are known. Obviously, upgrading the calculating speed and capacity of the microcomputer workstation executing the simulator would be helpful, but such increases are bought at the price of new, expensive equipment. It is not economically feasible to attempt to match the calculating speed and capacity needs of new simulated hardware designs by continuously upgrading the physical equipment executing the simulator. Other strategies must be developed. In general, these strategies rely on various means of reducing the number of calculations involved.
For example, U.S. Pat. No. 5,068,812, issued to Schaefer, et al. Nov. 26, 1991, relates to a method of reducing the number of calculations required for simulation of a logic circuit by marking those elements which require new evaluation due to a change in the value of their input signals. Elements which have not been marked will be skipped. The change in value of an input signal is referred to as an "event", and simulators that operate primarily using this principle are referred to as "event-based or event-driven simulators". In principle, for each new event, a new simulation pass must be performed.
U.S. Pat. No. 5,467,462 issued to Fuji Nov. 14, 1995 relates to an event-driven simulator that further allows an operator to pre-set the definition of an event and also identify the follow-up calculation.
U.S. Pat. No. 5,426,768 issued to Kanazawa points out that event-driven simulators are subject to deadlocks when different portions of the circuit would give conflicting instructions to a single sub-element. A hierarchy based on the time the event occurred is established, and calculations with a lower selection priority are delayed, thereby providing an orderly way of organizing multiple simulation passes.
U.S. Pat. No. 5,384,720 issued to Ku et al. Jan. 24, 1995 relates to a simplified method of identifying which events are important, that is, which changes in input value affect either the internal stored state of the circuit or the outputs of the circuit. A user specifies which outputs are important via a "watched nodes list" and then the simulator monitors those nodes over time, and identifies those nodes which have varying signal values during a defined time period. Then new simulation passes are performed on the logic circuit for events on those identified nodes.
U.S. Pat. No. 5,335,191 issued to Kundert et al. Aug. 2, 1994 relates to a circuit simulator having improved efficiency due to a rearrangement of the location where calculations take place. A simulation engine processor provides specific instructions to component processors as to exactly which type of calculation among several possibilities is desired. Lists of information as to the past or current value of calculations of interest within the component processors are maintained within the engine processor so that the assessment of whether an event of interest has occurred is made by the engine processor instead of the component processors. As a result, the complexity and expense of the component processors are reduced.
In general, it is known that simulation speed can be increased by grouping a set of elements together and modeling the aggregate behavior of the elements. Then the behavior of the group is simulated as a single object. Such groupings may include only two elements or thousands of elements. Once a grouping is made, the individual behavior of each element is subsumed into the overall behavior of the group. Significant simulation speed performance improvements can be achieved if the groupings can collect large numbers of elements. For example, U.S. Pat. No. 5,053,980, issued to Kanazawa Oct. 1, 1991 relates to an event-based simulator in which grouped events are labelled with an identifier (color), thereby allowing a limited amount of parallel processing.
The references described above all relate to event-driven simulators which operate at the hardware, or gate, level. They are typically used to analyze and verify the correct operation of an electrical circuit at various levels of detail. Typical users of such simulators are those who design, test and build the circuit.
Other types of circuit simulators are known, such as statically scheduled simulators. U.S. Pat. No. 5,455,928 issued to Herlitz Oct. 3, 1995 relates to a method of using a computer-aided design tool called a bus resolution block to represent groups of similar data paths in a logic circuit diagram. The bus resolution block is a program function that represents a table of possible input combinations and user-defined output responses. It allows an operator to bundle several data paths, and to resolve conflicts that occur where several drivers would attempt to act on the same input receiver. To achieve the desired end, the programmer first represents bi- or multi-directional data flow as multiple output drivers and input receivers, each with unidirectional data flow. Then the bus resolution blocks are inserted. This allows the programmer to design a statically scheduled simulation, that is, a simulation in which all data flow is represented as flowing in a single direction from outputs to inputs through each possible decision point in any given connection so that the data path is fixed at all times, that will accurately represent a circuit which employs multiple drivers or bidirectional data flow.
In the present case, the present inventors were not interested in verifying the correct assembly and interaction of all of the elements of a circuit, for example, to test the design of a new microprocessor chip. Rather, they were interested in questions that may arise when one is using the microprocessor as a control circuit in a larger system. In such a case, one ought to be able to presume that the original circuit functions correctly and explore the circuit's interaction with other circuits. Additionally, if the circuit is programmable, the user may be interested in the response of the overall system to various programming combinations. In that case, the question is not whether the microprocessor operates properly, but whether the pattern of instructions entered by the system designer are correct and complete: effort spent on verifying the underlying design of the microprocessor would not be directed to the inquiry of interest. For example, in a computer system where the central processing unit (CPU) is one circuit and memory is another, the present inventors would be interested in populating the memory with instruction patterns for the CPU to operate on. Any action by the simulator to test the operation of transistors or groups of transistors within either the memory's circuit or the CPU's circuit would only waste time or provide misleading results.
Another factor to be considered with respect to event-driven simulators is their treatment of time. Since events in an event-driven simulator are asynchronous, that is, not bound to a fixed time, any number of events can occur simultaneously. Therefore, the passage of time itself must be treated as an event which must be monitored, and the size of the time increment will determine the resolution and accuracy of the event-driven simulation. Consequently, the simulation of one system level clock cycle for a simple microcomputer system (CPU and memory) may require the simulation of thousands of events. Furthermore, the addition of a peripheral, such as a serial communication channel, will add even more events per clock cycle, potentially halving the simulator's overall performance.
In contrast to event-based simulators, a cycle-based simulator builds on the characteristic of large electrical systems that they are usually synchronous in nature. That is, the activity of several circuits is co-ordinated: their activity is commonly initiated and terminated by a clocking signal which can be set for a given period of time in seconds. The electrical system, therefore, is regulated by a clock signal, and all behavior within the system occurs within a given, regular period of time which can be referred to as clock signal transitions or cycles. A simulator might take advantage of this feature and optimize its performance by compressing the execution of multiple simulation passes for an element or group of elements into a single simulation pass with respect to a clock signal transition. This approach is viable because any output signals that change while the clock signal is static would not necessarily require resimulation of all affected inputs if the inputs are also regulated by the clock signal. The hazard of this approach is that some simulation accuracy may be lost if there is no method to deal with important information which may have changed while the clock signal was static. An example of such information would be the speed of a wheel or the pressure on a brake pedal. Therefore, for real-world testing, some method must be found to accommodate information which may not change according to a clocking signal, that is, asynchronous information. The simulator of the present invention may be regarded as a hybrid cycle-based simulator with asynchronous information support capability.
A simulator that takes advantage of the regulatory behavior of a clock signal is known as a cycle-based simulator. While such simulators present interesting possibilities, the known commercially available cycle-based simulators are still too slow for satisfactory performance in large electronic systems. See for example the SpeedSim, Inc. Product Brochure, "SpeedSim/3 Software Simulator" available at http://www.speedsim.com, which as of Oct. 20, 1996 offered verification speeds of 10 to 1000 cycles per second. This product, like the event-based references discussed above, is directed to the design of electrical circuits such as microprocessor chips, not verification of software on electronic systems for real-world applications.
Another recently introduced industry example is the "Seamless Co-Verification Environment (CVE) by Microtec, Mentor Graphics Corp., available at http://www.mentorg.com. This product is believed to combine an Instruction Set Simulator (memory and CPU) with a standard event based simulator (Verilog/VHDL). This product essentially replaces some well understood hardware behaviors, such as accessing memory, with custom code that assumes the hardware is already verified. Per a May 20, 1996 Electronic Engineering Times article (currently available at www.techweb.com/se/directlink.cgi?EET19960520S0022), the product has a performance of about 3,000 instructions per second. The higher rates of simulation are achieved at the expense of shutting off additional circuit blocks such as clocking signals, simulation blocks, and sacrificing some accuracy for speed.
In order to be of practical value, a cycle-based simulator for an electronic system should run at least about 10,000 cycles per second, preferably at least about 50,000 cycles per second, and more preferably at least about 100,000 cycles per second. Further, it must provide some mechanism to ensure that accuracy of simulation is not lost due to truncation of simulation activity by the clocking signal, and must accommodate asynchronous information, that is, information that must be updated continuously because it does not conform to a clocking signal.